A data processing system includes a central processing unit (CPU) that executes instructions and thereby manipulates data. The instructions and data are stored in a memory system, which is typically isolated from the CPU. The CPU interacts with the memory system through a memory interface. The functioning of the memory interface is predominantly under the control of the CPU, and is performed by a memory controller. The memory controller can be integrated tightly with the CPU, such as on the same silicon chip as the CPU, or it can be included with other components of the data processing system, one such component often referred to as a north-bridge chipset.
There are many types of memory. One type is referred to as dynamic random access memory (DRAM). A DRAM system can include several known types of DRAM, of which double data rate (DDR) is an example. One may refer to the memory controller that governs the interface to the DRAM system as a DRAM controller. Furthermore, one may refer to a memory controller that interfaces a CPU to DDR DRAM as a DDR DRAM controller.
DDR DRAM conforms to industry standard electrical and protocol standards set forth by the Joint Electron Devices Engineering Councils (JEDEC). These standards define how the contents of the DRAM is accessed (read), and stored (written). The DDR family of standards has now been enhanced to include standards known as DDR2 and DDR3. The interface to any of these DDR DRAMs is accomplished primarily through two signal classes, DQ (data) and DQS (data clock).
The JEDEC standard interface specifies that during a read operation, the DDR DRAM will issue these two signal classes at the same time, a manner commonly referred to as “edge aligned”. In order for the DRAM controller to correctly acquire the data being sent from the DDR DRAM, the DRAM controller typically utilizes a delay-locked loop (DLL) circuit to delay the DQS signal so that it can be used to correctly latch the DQ signals. For similar reasons, the DRAM controller also utilizes DLL circuits to center the outgoing data on transitions of DQS.
A DLL must lock to a reference signal to keep the delay of the output signal substantially constant over process, voltage, and temperature variations. Some DLLs continuously maintain lock to a reference signal, whereas others intermittently lock to a reference signal while continuously using the voltage of the loop filter to set the delay, since this voltage decays slowly. During the time that the DLL is reacquiring lock, it cannot be also supporting a read operation so system performance is diminished.
Known DLLs have addressed this problem in several ways. One solution is to duplicate the receive DQS DLL and alternate between the two DLLs (sometimes referred to as a “Gatling gun” solution). While one DLL is reacquiring lock, the other is receiving and delaying DQS. Periodically, the two DLLs are swapped so that the DLL that has just reacquired lock is used to delay DQS and the other DLL can now be connected to the reference clock and it can reestablish lock. This solution is costly since it requires an extra DLL for each data nibble of DRAM controller transceiver, resulting in higher system cost and ultimately lower system performance.
Another similar solution also involves a second DLL that is constantly maintaining lock to a reference clock signal. This second DLL is often called a replica DLL. The first DLL permanently receives the DQS signal and the delay cells therein receive the feedback control bias voltage from the loop filter of the replica DLL, such that the first DLL maintains approximate lock to the replica DLL. The first DLL does not require a phase detector or loop filter because the required feedback control bias voltage is provided by the replica DLL. This solution not only has the disadvantages of a duplicated DLL, but also suffers from decreased performance since the replica DLL cannot track the second DLL perfectly.
Yet another solution involves periodically pausing the read transaction for a time adequate to reestablish lock using a reference clock signal. After the receive DQS DLL has once again established lock, then the read transaction can be restarted. This solution has the disadvantage of lowering system performance.